[JumpThreading] Don't restrict cast-traversal to i1
Summary:
In D17663, JumpThreading learned to look trough simple cast instructions,
but only if the source of those cast instructions was a phi/cmp i1
(in an effort to limit compile time effects). I think this condition
is too restrictive. For switches with limited value range, InstCombine
will readily introduce an extra `trunc` instruction to a smaller
integer type (e.g. from i8 to i2), leaving us in the somewhat perverse
situation that jump-threading would work before running instcombine,
but not after. Since instcombine produces this pattern, I think we
need to consider it canonical and support it in JumpThreading.
In general, for limiting recursion, I think the existing restriction
to phi and cmp nodes should be sufficient to avoid looking through
unprofitable chains of instructions.
[hurd] Make getMainExecutable get the real binary path
On GNU/Hurd, llvm-config is returning bogus value, such as:
$ llvm-config-6.0 --includedir
/usr/include
while it should be:
$ llvm-config-6.0 --includedir
/usr/lib/llvm-6.0/include
This is because getMainExecutable does not get the actual installation
path. On GNU/Hurd, /proc/self/exe is indeed a symlink to the path that
was used to start the program, and not the eventual binary file. Llvm's
getMainExecutable thus needs to run realpath over it to get the actual
place where llvm was installed (/usr/lib/llvm-6.0/bin/llvm-config), and
not /usr/bin/llvm-config-6.0. This will not change the result on Linux,
where /proc/self/exe already points to the eventual file.
Patch by Samuel Thibault!
While making changes here, I reformatted this block a bit to reduce
indentation and match 2 space indent style.
[LSR] Don't force bases of foldable formulae to the final type.
Summary:
Before emitting code for scaled registers, we prevent
SCEVExpander from hoisting any scaled addressing mode
by emitting all the bases first. However, these bases
are being forced to the final type, resulting in some
odd code.
For example, if the type of the base is an integer and
the final type is a pointer, we will emit an inttoptr
for the base, a ptrtoint for the scale, and then a
'reverse' GEP where the GEP pointer is actually the base
integer and the index is the pointer. It's more intuitive
to use the pointer as a pointer and the integer as index.
[SCEV] Don't expand Wrap predicate using inttoptr in ni addrspaces
Summary:
In non-integral address spaces, we're not allowed to introduce inttoptr/ptrtoint
intrinsics. Instead, we need to expand any pointer arithmetic as geps on the
base pointer. Luckily this is a common task for SCEV, so all we have to do here
is hook up the corresponding helper function and add test case.
James Clarke [Mon, 23 Mar 2020 10:59:23 +0000 (10:59 +0000)]
[Sparc] Include __tls_get_addr in symbol table for TLS calls to it
Last-Update: 2018-02-14
Global Dynamic and Local Dynamic call relocations only implicitly
reference __tls_get_addr, but it still needs to be in the symbol table
to be bound at link time otherwise it fails to link. For details, see
https://sourceware.org/bugzilla/show_bug.cgi?id=22832.
Gbp-Pq: Name sparc64-add-missing-tls-get-addr.diff
lldb-server exec users always /usr/bin/lldb-server. Server is required
for any debugging with lldb which makes it unusable unless default version
package has been installed. Small changes to code and debian/rules allows
a workaround for lldb-server start up.
To use this one needs to add cmake defination during configure. eg
-DDEBIAN_VERSION_SUFFIX=-$(LLVM_VERSION)
Better implementation would be to use /usr/share/llvm-$(VERSION)/bin but
that change seems to require a big change to the path handling code
which could then break something else.
This probably should have upstream bug but I couldn't find any existing report.
Gbp-Pq: Name lldb-addversion-suffix-to-llvm-server-exec.patch
Sylvestre [Mon, 23 Mar 2020 10:59:23 +0000 (10:59 +0000)]
Silent a test failing on yakkety amd64
Last-Update: 2016-08-26
/tmp/buildd/llvm-toolchain-snapshot-4.0~svn279801/test/tools/llvm-symbolizer/print_context.c:16:11: error: expected string not found in input
// CHECK: inc
^
<stdin>:1:1: note: scanning from here
_fini
^
<stdin>:1:3: note: possible intended match here
_fini
^
Peter Wu [Fri, 4 May 2018 13:55:26 +0000 (15:55 +0200)]
[PATCH] [clang] cmake: resolve symlinks in ClangConfig.cmake
Ensure that symlinks such as /usr/lib/cmake/clang-X.Y (pointing to
/usr/lib/llvm-X.Y/lib/cmake/llvm) are resolved. This ensures that
CLANG_INSTALL_PREFIX ends up to be /usr/lib/llvm-X.Y instead of /usr.
Partially addresses PR37128
Gbp-Pq: Name 0001-tools-clang-cmake-resolve-symlinks-in-ClangConfig.cmake.patch
Peter Wu [Fri, 4 May 2018 13:43:06 +0000 (15:43 +0200)]
[PATCH] [llvm] cmake: resolve symlinks in LLVMConfig.cmake
Ensure that symlinks such as /usr/lib/llvm-X.Y/cmake (pointing to
lib/cmake/llvm) are resolved. This ensures that LLVM_INSTALL_PREFIX
becomes /usr/lib/llvm-X.Y instead of /usr.
Partially addresses PR37128
Gbp-Pq: Name 0001-llvm-cmake-resolve-symlinks-in-LLVMConfig.cmake.patch
Command Output (stderr):
--
/build/llvm-toolchain-snapshot-4.0~svn279916/test/tools/gold/X86/start-lib-common.ll:22:10: error: expected string not found in input
; CHECK: @x = common global i32 0, align 8
^
<stdin>:1:1: note: scanning from here
; ModuleID = '/build/llvm-toolchain-snapshot-4.0~svn279916/build-llvm/test/tools/gold/X86/Output/start-lib-common.ll.tmp3.o'
^
<stdin>:4:1: note: possible intended match here
@x = common global i32 0, align 4
^
# Without this patch, the first local include of unwind.h might, with the
# __has_include_next, try to include the one from the system.
# It might be /usr/include/clang/3.4/include/unwind.h
# Because of the #ifndef __CLANG_UNWIND_H, it might never include any declaration
# from the system.
projects / llvm-toolchain-6.0.git / log